Software services provide a variety of opportunities for enterprises and consumers to conduct business and personal affairs. By and large, these services are now interconnected over the Internet and the World-Wide Web (WWW). Furthermore, devices, which can access the WWW, are becoming increasingly smaller, mobile (portable), even more affordable.
One concern that enterprises and consumers have is over the security of their Internet transactions; and as Internet transactions steadily increase so too does malicious activities. Another concern is whether a transaction completes properly. In fact in some cases, a transaction, such as a banking transaction, may even be governed by laws or regulations that dictate a certain degree of security and tracking, which has to occur.
Transactional event logging does provide some degree of auditing and reporting about the operational capabilities associated with software services. However, it may also present security holes that are not anticipated. For example, too much detail captured in logged events, which are raised during a financial transaction, may unknowingly provide an intruder with the necessary information to penetrate a bank account or to identify particular resources that can be attacked. Event logs may also be manipulated after the fact to remove traces of malicious behavior or even to direct attention towards an innocent third party that is not involved at all.
Generally, event capturing and logging are application or service specific. That is, different services may use different logging formats and may capture different event information. Moreover, although SYSLOG has been available for many years, it not universally accepted and used. In fact, logs may be written in proprietary formats to text files (.txt extensions), log files (.log extensions), and others. Thus, compatibility among services, which interact and record events, is problematic.
Another issue is that event log security is often not addressed at all. There is a belief in the industry that should a service fail the log information should be easily retrievable and accessible to assist in debugging and resolving the problem. So by practice and by the perceived nature of event logging, security practices are often absent altogether.
Still another problem exists in that in many instances recorded events include their own proprietary taxonomy. Such recorded events may be meaningless unless their overall context or taxonomy is also known. Each service or application seems to proliferate and use its own taxonomy for events. Even standard taxonomies, such as SYSLOG, have proliferated different versions that are more customizable and extensible then previous versions. Consequently, event taxonomies tend to be extremely specific to the application or service, which raises the events in the first instance.
Thus, what are needed are techniques, which allow for improved event recording and processing.